How to Get a Real Answer Out of a Status Update

Your car has been at the garage for two weeks. You call. The mechanic says they changed the alternator and found another issue with the left phalange.

Every word of that is true, and you still don't know when you're getting your car back, what it will cost, or whether to start looking at bus timetables.

Most status updates arrive in exactly that condition. Nothing in them is wrong. You can't act on any of it, so you leave the meeting with vague unease and no decision.

The gap closes with four questions. Each one catches a different thing that goes missing from an update, and you can use all four in the same fifteen-minute conversation.

The state question

"What's the status?" gets you a paragraph.

Ask instead: Which state is each milestone in? and say the word.

Give the team the words in advance so there are only four available: "on track," "at risk," "blocked," and "done."

• "On track" means the date holds with no help from you.
• "At risk" means the date holds only if something specific goes right.
• "Blocked" means work has stopped and someone outside the team has to move.

Anything that can't be assigned one of those four words is a milestone nobody actually owns, which is a more useful finding than a status.

The reason this works is that people will happily narrate ambiguity for ten minutes and won't say the word "blocked" out loud without being asked. Say it once yourself, in your own update to your boss, and it stops being a confession.

The age question

Ask: What's been in the same state the longest?

Sonya Siderova, a Kanban coach who trains delivery teams on flow, runs daily meetings off an aging chart rather than a task list. Every item in progress carries the number of days it's been sitting, and the meeting discusses only the items that have taken longer than 95% of comparable work already finished. On a three-person team, that usually means two items. Everything else gets no airtime at all.

Do the arithmetic on your version. Ten people, fifteen items in progress, and thirty minutes to walk the board are five person-hours a week spent describing work that's moving fine.

You don't need software for this task. Ask for the date each open item entered its current state and sort by that column. The three oldest items are on your agenda, and the conversation about them boils down to one question: what has to happen for this to move, and who is responsible for it?

The consequence question

Ask: What does that mean for the date and the number?

An update that says "we discovered problem A also affects user group B" is a fact. The version you can act on says the problem is bigger than we thought; fixing it properly adds support for function Y, which covers another 12% of the target population; it pushes the release to 6 June; and it moves the goal metric by four points.

Same discovery. One version needs you to do the reasoning with a fraction of the context. The other tells you what it costs and what you get.

Make this a standing requirement. Any update that reports a change also reports what the change does to the delivery date, the cost, and the one metric the project is meant to move. When someone can't answer, that's the work for the week.

The input question

Ask: Which of these numbers can we actually move this week?

Colin Bryar and Bill Carr tell this story in Working Backwards, their account of two decades inside Amazon. The company spent a period tracking new detail pages created as its measure of selection, on the theory that more pages meant more choice. Teams responded exactly as instructed and added thousands of items. Sales didn't rise. Inventory holding costs did, and low-demand stock took warehouse space that faster items needed. (Working Backwards by Colin Bryar and Bill Carr)

The metric evolved through four versions before it became useful: number of detail pages, then page views, then the percentage of page views where the item was in stock, and finally the percentage in stock and ready for two-day shipping.

Revenue, satisfaction, and adoption tell you what happened. They arrive too late to act, and nobody can change them directly on a Tuesday. Ask your team which of the numbers in the update they can affect through a decision they make this week. Those are the numbers worth reviewing weekly. The rest belong in the monthly review.

What to do with all four

Send the four questions to whoever reports to you before the next update so the answers arrive in the document instead of getting extracted live in the room.

Ask for a four-sentence summary at the top.

For each milestone,

• State its current status;
• The most significant change since the last update;
• How that change affects the date, and
• What you need from the reader.

Anyone who can't compress it to four sentences hasn't finished thinking about it; the compression is the useful part.

Add the entry date to every open item this week. One column. Sort the open items by entry date before your next meeting, and limit the agenda to the three oldest.

Then answer the last question yourself, out loud, at the end of the update: Why does this information matter to the people reading it, and what happens next? Nobody else in the room has your context, which makes the answer your job rather than theirs.

The mechanic who tells you ‘the battery is fixed, the engine is being looked at, it's two more days at no extra cost or five days and another hundred pounds, and you'll know by ten tomorrow’ has told you nothing you'd call impressive. You just know exactly where you stand, which is all you wanted at the start of the call.